Debug: imaris_to_ome_zarr tweaks + add KI3 batch2 samples#70
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
imaris_channel_to_zarr.pycorrectly writes intermediate channel files aszarr.zipusingzarr.ZipStore(path, mode='x'), butimaris_to_ome_zarr.pywas reading those same files by passing the path string directly tozarr.open()andda.from_zarr(). Neither call auto-detects a.zarr.zippath as a ZipStore — they default to treating it as a directory store with mode'a', which causes zarr to attempt writing.zgroupmetadata into what is actually a zip file, resulting in aFileExistsError.This is made worse by the
shadow: "minimal"directive on theimaris_to_ome_zarrrule, which symlinks the input.zarr.zipfiles into the shadow directory — the file-vs-directory conflict happens immediately on open.Fix:
Explicitly open the input zarr files as
ZipStoreobjects in read mode before passing them tozarr.openandda.from_zarr, consistent with how the writer script already handles them.